1. Field of the Inventions
This invention blocks unsolicited e-mail messages, commonly known as SPAM, from a client's e-mail server; while reducing Internet traffic, server to client traffic, and local storage.
2. Background Information
E-mail has become an important means of communications. Unfortunately, unsolicited e-mail messages, commonly referred to as SPAM, is cluttering this communications channel. This unsolicited e-mail wastes Internet bandwidth, local area network bandwidth, and storage. This translates into lost productivity, increased computing, and increased communication costs. Some of this unsolicited e-mail is also offensive and inappropriate for non-adult audiences.
The spammer collects a list of e-mail address, append these addresses to their message, and queues these messages on their e-mail server (message transfer agent), 2, in FIG. 1. He then connects their e-mail server to the Internet, 1, via in a rogue Internet service provider, a dial-up connection, a digital scriber loop (DSL) connection, or a cable modem connection and sends out their message to the gateway message transfer agents, 5, associated with each e-mail address. These gateway message transfer agent either stores the message in the e-mail mailbox associated with the client, 3, or forwards the message to a another message transfer agent (MTA) on the same local area network.
There are four basic approaches to trying to detect junk e-mail messages. One approach used a community set of rules to determine whether or not a message is spam. This approach is used in Razor, an open source Linux solution, and by companies such as CloudMark (based on Razor) and SpamNet. The problem is getting the user community to agree on a common set of rules.
A second approach uses a set of rule base filters which are periodically updated by the provider and downloaded by the client to determine whether or not a message is spam. The problem is that the set of rules have to be updated and downloaded periodically.
A third approach uses a set of permissions to determine whether or not a message is spam. The problem is that it is not possible for somebody not on the user's permission list to send a message to the user.
A fourth approach uses a “whitelist” and a “blacklist” to determine whether or not a message is spam. The problem is that the spammers are constantly changing their return address and declared domain names.
There are three basic ways of implementing these approaches. One implementation approach is in the Message transfer agent. This approach add some rules to the MTA. The problem is that the MTA program is complicated and inflexible. This limits the kind of rules that can be implemented.
A second implementation approach involves placing the filters between the e-mail client and the Message Transfer Agent. The problem is that some of the information which can be used to help determine whether or not a message is spam is lost or buried.
A third implementation approach involves adding some filters to the e-mail client, Mail User Agent (MUA). The problem is that the e-mail client add-in interface is not an open standard. This leads to compatibility problems.
A problem with these approaches is that they are “reactive.” The spam has already been received by the server and relayed via a local area network to client's computer. The spam message has already consumed the server's Internet bandwidth, local area network bandwidth, and client storage.
Another problem with these approaches is that they based on the from-address, subject line, or content of the message; all of which are easy to forge or change.